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[57] ABSTRACT 

The present invention is directed to a system and method for 
modifying a class file for the purpose of instrumentation, 
debugging, benchmarking, or making functional modifica- 
tions to the class file. In addition, the present invention 
makes necessary changes to the components of the class file, 
so that the class file will pass the class file verifier before 
being executed. A class file is deconstructed into its 
components, and then selected components of the class file 
are modified by adding, deleting, or changing code within 
the components. The class file is then reconstructed, follow- 
ing all class file constraints imposed by the class file verifier. 
The present invention may also be used to modify selected 
code attributes of a network browser (i.e. a web browser) so 
that downloaded applets are saved to memory and modified 
before being executed by the information handling system. 
Class files may be modified without access to the source 
code, and the modified class files meet all constraints 
imposed by a class file verifier. 
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SYSTEM AND METHOD FOR DYNAMIC 
MODIFICATION OF CLASS FILES 

FIELD OF THE INVENTION 

The present invention relates to information processing 
systems and, more particularly, to software tools and meth- 
ods for modifying class files for the purpose of performance 
instrumentation and measurement, debugging, 
benchmarking, and making functional modifications to the 
class files. 

BACKGROUND OF THE INVENTION 

The number of application programs written in Java is 
growing rapidly in number. One of the key reasons for this 
is the portability of Java code. A brief overview of Java is 
given below. For more detailed background information on 
the Java Virtual Machine and the Java language, see Lind- 
holm and Yellin, "The Java Virtual Machine Specification," 
published by Addison- Wesley. Note that specifications for 
the Java language and the Java Virtual Machine have been 
released by Sun Microsystems, Inc. 

The Java language is an object-oriented programming 
language which is compiled to run on a Java Virtual 
Machine ("Java VM"). A Java VM is a computer which runs 
on top of the existing hardware and operating system of 
another computer system. Because the specifications for the 
Java VM have been published, it is possible to write a Java 
VM to work with any hardware and/or operating system. 
Java programs are compiled into bytecode, which will run 
on any Java VM. The Java VM essentially acts as an 
interpreter between the Java bytecodes and the system on 
which the Java program is executing. 

There are four major components to a Java VM, all of 
which are implemented in software. The four components 
are the registers, the operand stack, the garbage collected 
heap, and the method area. The method area contains the 
method code (i.e. the compiled Java code) and symbol 
tables. The compiled Java code, i.e. the bytecode, consists of 
a set of instructions. Each instruction consists of a one byte 
opcode followed by any needed operands. 

Compiled Java programs are typically referred to as Java 
class files. Many Java class files are downloaded from the 
Internet for execution on a user's computer system. One of 
the first steps performed by a Java VM is called verification. 
A class-file verifier (part of the Java VM) ensures that the file 
truly is a Java class file and will execute without violating 
any Java security restrictions. 

The class file verifier first checks to determine if the class 
file being loaded is of the correct class file format. This is 
done by examining the first four bytes of the class file. All 
Java class files must begin with the "magic number" (i.e. 
OxCAFEBABE). A version number follows the magic 
number, and the class file verifier checks to ensure that the 
class file being loaded is compatible with the VM loading it. 
The verifier also checks the information in the constant pool 
and other sections of the class file for consistency. 

During the linking phase, the verifier ensures that all 
classes except for the ^jecT dassjiave a superclass and that 
all field and method references in the constant pool have 
valid names, classes, and type descriptors^ In addition, the 
verifier checks the code array of the code attribute for each 
method to ensure that all local variables contain values of the 
appropriate type, that methods are called with the appropri- 
ate arguments, and that fields are assigned correct values. 
The verifier also checks the operand stack for correctness. 
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Finally, during execution, the verifier checks to ensure 
that a referenced type is allowed for instructions referencing 
a type. If an instruction modifies a field or calls a method, the 
verifier checks to ensure that the field or method is available 

5 and that the calling method is allowed to access the field or 
call the method. 

Often, developers would like to measure the performance 
of a particular Java application in order to identify the 
sources of delay in the application. Typically, however, the 

10 developer only has access to the Java class file and not to the 
source code. This makes it difficult to insert instrumentation 
code for measuring and analyzing performance. The Java 
runtime environment currently provides limited support for 
performance measurement and analysis. In addition, the 

15 class file verifier will not typically allow a class file to 
execute if it does not comply with all requirements noted 
above. This means that instrumentation code cannot simply 
be added into the class file, as this would most likely cause 
the class file verifier to reject the class file. Similar problems 

20 occur whenever a developer desires to add, delete, or modify 
any code in an existing class file. For example, a developer 
may desire to add code for the purpose of performing 
benchmark tests or debugging. A developer may also desire 
to add, delete, or modify code for the purpose of making 

25 functional modifications to the class file. 

Consequently, it would be desirable to have a system and 
method for modifying class files by adding, deleting, or 
modifying code within the class files. It would be desirable 
to have a system and method which would follow all class 

30 file constraints and thus would not cause class files to be 
rejected by a class file verifier. 

SUMMARY OF THE INVENTION 

35 Accordingly, the present invention is directed to a system 
and method for modifying a class file for the purpose of 
instrumentation, debugging, benchmarking, or making func- 
tional modifications to the class file. In addition, the present 
invention makes necessary changes to the components of the 

40 class file so that the class file will pass the class file verifier 
before being executed. 

The present invention deconstructs a class file into its 
components and then modifies selected components by 
adding, deleting, or changing code within the components. 

45 The class file is then reconstructed, following all class file 
constraints imposed by the class file verifier. The present 
invention also may be used to modify selected code 
attributes of a network browser (i.e. a web browser) so that 
downloaded applets are saved to memory and modified 

50 before being executed by the information handling system. 
One embodiment of the present invention is an informa- 
tion handling system capable of performing the method 
described above. Another embodiment of the present inven- 
tion is a computer readable medium containing sets of 

55 instructions capable of executing the method described 
above. 

An advantage of the present invention is that class files 
may be modified without access to the source code. Another 
advantage of the present invention is that the modified class 
60 files will meet all constraints imposed by a class file verifier. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing and other features and advantages of the 
65 present invention will become more apparent from the 
detailed description of the best mode for carrying out the 
invention as rendered below. In the description to follow, 
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reference will be made to the accompanying drawings, to break the class file into its many parts, or elements (step 

where like reference numerals are used to identify like parts 206). Because the Java class file specification is published 

in the various views and in which: by Sun Microsystems, Inc., it is possible to parse the class 

FIG. 1 is a block diagram of an information handling file into its constituent parts. This is typically accomplished 

system capable of executing the method of the present 5 wiih a .class file reader. The design and implementauon of a 

• t - . class file reader is not discussed here. Given the published 

m 1 ' class file specification, a skilled programmer could develop 

FIG. 2 is a flow chart illustrating a method of loading a an( j implement a class file reader to break a class file into its 

class file from a file system and transforming the class file elements. 

according to the teachings of the present invention; ^ 0nce me class file bas been deconstructed, it can then be 

FIG. 3 is a flow chart illustrating a method of modifying transformed, or modified (step 208). The modifications may 

a network browser according to the teachings of the present include any combination of adding, deleting, or modifying 

invention; code and linkage information. For example, one or more 

FIG. 4 is a flow chart illustrating a method of download- code segments, each consisting of one or more lines of code, 

ing a class file from a network using the modified browser 15 may be added at various points throughout the class file. In 

from FIG. 3 and transforming the downloaded class file the preferred embodiment, these lines of code are added to 

according to the teachings of the present invention; instrument the Java class file for performance reasons. 

FIG. 5 is a flow chart illustrating one embodiment of the However, a class file may be modified for many reason 

present invention; including, but not limited to debugging, functional 

^ . a '.^-,1 j . -1 j • modifications, or benchmarking. After modification, the 

FIG. 6 is a flow chart illustrating further details regarding 20 * tA/t <, 1ft \ At tU * - ! *u 

. . . . j . f r a a • a class file is then reconstructed (step 210). At this point, the 

the changes that must be made to transformed code in order ^ Qf ^ ^ ^ fi £ can be 7 xecuted 

to satisfy a class file verifier; and ^ by ^ ^ ^ ^ evefy method me 

FIG. 7 is a flow chart illustrating the execution of a ^ me may b< instrumented or only some of the methods 

modified method. ^ may be mslrU mente<I. If only some of the methods are to be 

DETAILED DESCRIPTION OF A PREFERRED instrumented, it is possible to partially deconstruct the class 

EMBODIMENT OF THE INVENTION file and instrument onlv the desired methods. 

Java class files are often downloaded from a network, 

The invention may be implemented on a variety of such as the Imerae t. The method of the present invention 

hardware platforms, including personal computers, ^ may be practiced on any j ava class file, regardless of how 

workstations, embedded systems, mini-computers, and lhe dass fik ^ obtaine d. jf me fii c j s obtained from a 

mainframe computers. Many of the steps of the method network, such as the Internet, it is typically loaded imme- 

according to the present invention may be advantageously diately imo the Java ^ ^ exeC uted. Such Java class files 

implemented on parallel processors of various types. are nol usua u y saved on the user's hard disk or in a file 

Referring now to FIG. 1, a typical configuration of an 35 system. In some cases (e.g., embedded systems), there may 
information handling system that may be used to practice the not be a hard disk or local file system available. Class files 
novel method of the present invention will be described. The downloaded from a network are typically loaded directly 
computer system of FIG. 1 has at least one processor 10. ml0 memory by the Java VM ClassLoader. Therefore, it is 
Processor 10 is interconnected via system bus 12 to random necessary to intercept the class file at the loader and trans- 
access memory (RAM) 16, read only memory (ROM) 14, ^ f orm j Us memory image directly. This is accomplished by 
and input/output (I/O) adapter 18 for connecting peripheral modifying a web browser so that it dynamically modifies 
devices such as disk units 20 and tape drives 40 to bus 12, c i ass files coming from the network, as described below with 
user interface adapter 22 for connecting keyboard 24, mouse reference to FIG. 3. In the described embodiment, the web 
26 having buttons 17a and 17b 7 speaker 28, microphone 32, browser is also a Java file, and thus the same method used 
and/or other user interface devices such as a touch screen 45 l0 modify the web browser is used to modify downloaded 
device 29 to bus 12, communication adapter 34 for connect- j ava class file. Also note that the method of the present 
ing the information handling system to a data processing invention works even with Java files containing a security 
network, and display adapter 36 for connecting bus 12 to signature, as the method of the present invention is used 
display device 38. after the security signature verification. 

Communication adaptor 34 may link the system depicted 50 The method of the present invention may be used to 

in FIG. 1 with hundreds, or even thousands, of similar modify the web browser. For example, a Java enabled web 

systems or other devices, such as remote printers, remote browser includes Java Runtime class files, which are used to 

servers, or remote storage units. The system depicted in FIG. nin Java applets coming across the network. The Java 

1 may be linked to both local area networks (sometimes Runtime is modified, using the method of the present 

referred to as Intranets) and wide area networks, such as the 55 invention so that it provides functionality to modify all class 

Internet. files that the Runtime loads across the network for subse- 

Referring now to FIG. 2, a method for modifying a class quent execution. In other words, the method of the present 

file will now be described. The present invention will be invention is invoked twice — first, to modify the web 

described with reference to modifying a Java class file. The browser, and second to cause the web browser to modify a 

system and method of the present invention may be imple- 60 downloaded class file. 

mented in any Java VM environment (e.g., IBM JDK, Referring now to FIG. 3, a method for modifying a 

Microsoft SDK, Sun JDK, Sun JavaOS JVM, or Netscape network browser, or web browser, is illustrated. Note that 

J RE) or on any type of class file where an intermediate code the web browser class files are typically stored in the file 

abstraction (e.g., bytecode) is used. system. The first step then is to locate the ClassLoader file, 

Still referring to FIG. 2, a user first selects a class file to 65 which is part of the Runtime class files (step 302). A 

load from a file system (step 202). The selected class file is reference to the Modifier class is inserted in the constant 

opened and loaded into memory (step 204). The next step is pool section of the ClassLoader (step 304). Next, a call to the 
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modifier class is inserted into the ClassLoader instance at a 
point where it has received the class file and is about to give 
it to the VM to be instantiated (step 306). The modifications 
to the received class are carried out in a call to the "MODI- 
FIER class." Finally, the modified ClassLoader is saved 
(step 308). The user may then proceed to select class files to 
download and modify from a network, such as the Internet. 

Referring now to FIG. 4, a method for downloading and 
modifying class files, from a nerworkwill now be described. 
As shown in FIG. 4, a user selects a class file to download 
(step 402). The class file is downloaded using a web browser 
which has been modified according to the method described 
above with reference to FIG. 3 (step 404). The class file is 
then saved to a memory area (step 406). The remaining steps 
are as discussed in FIG. 2. The class file is opened and 
loaded (step 408), broken into elements (step 410), trans- 
formed (step 412), and then reconstructed (step 414). 

Referring now to FIG. 5, additional details regarding the 
method of the present invention will now be described. FIG. 
5 illustrates one embodiment of the present invention, i.e. 
adding code for the purpose of instnimentation.^Code may 
be added to, deleted from, or modified in the Java class file 
for many reasons, including instrumentation, benchmarking, 
performance tuning, modifying functionality, applying func- 
tional or performances patches, etc. While the invention will 
be described with reference to adding instrumentation code 
for the purpose of performance measurement and analysis, 
this is not meant to limit the present invention. 

FIG. 5 illustrates the steps of transforming the class file 
components and then reconstructing the class file, specifi- 
cally for the purpose of adding performance instrumentation 
code at the entry and exit of every method contained in the 
class file. This is, of course, only one embodiment of the 
present invention, and is discussed in detail for illustrative 
purposes. The unique system and method of the present 
invention may be used for many purposes, as discussed 
above. 

Every method in a class file has a unique method signa- 
ture. Tlie method signature is not the same as the security 
signature discussed above. A method signature is a string 
containing the method name and an encoding of the number 
and types of formal parameters to the method. The Java 
language specification describes this encoding in such a way 
as to guarantee uniqueness for every method in a class. For 
example, a method referred to as "method_X" which takes 
a single integer as a formal parameter would have the 
method signature "method_X(l). A class file can not have 
two methods with the same method signature. If code is 
written such that a class file would have two methods with 
the same method signature, a compiler error occurs. The 
performance instrumentation takes the form of a trace hook 
that is written to a trace facility every time the instrumented 
method is either entered or exited. Each hook is uniquely 
identified with a major code and a minor code. 

Referring now to FIG. 5, assume that a class file has been 
opened, and a hook definition file (HDF) has also been 
opened for creation. The HDF will be used to record 
information about the mapping between specific trace hook 
major and minor codes and the methods into which they are 
being inserted. For example, consider class "TEST" having 
two methods, <method_X> and <method_Y>. As each 
method is instrumented with an entry and exit hook, entries 
will be made in the HDF file that identify the major and 
minor codes for those hooks, along with the class name and 
method signature. The entries, for example, may look as 
follows: 



10 



15 



20 



25 



45 



50 



55 



60 



65 



major/minor 


class/method 


22/01 


TEST.method_X(l) 


22/81 


TEST.method_X_exit 


22/02 


TEST.method_Y() 


22/82 


TEST,mcthod_Y_exit 



In the above excerpt from a possible HDF file, major code 
22 and minor code 01 are associated with the trace hook 
placed at the entry of method_X in class TEST. The method 
signature (e.g., "(I)") is recorded to allow for clear discrimi- 
nation between overloaded methods (i.e. class constructors 
are frequently overloaded, and the only way to discriminate 
between one constructor and the other is to examine the 
method signature). 

Note that an HDF file is not a requirement but serves as 
an optimization in implementing the trace hooks. The result- 
ing trace stream consists of sequences of major/minor codes 
(with time stamps). A postprocessing phase takes the HDF 
file and merges it with a trace stream, resulting in a trace 
stream that identifies methods/classes by name. The follow- 
ing is an example of a trace stream that may be generated by 
merging trace data with the above HDF file: 





major 


minor 


times lamp 


description 


30 


12 




15585860940 


Dispatch thread: el8507a0 




22 




15585833507 


ENTRY: TEST.method_X(I) 




12 




15:985845671 


Dispatch thread: cl7d5bb0 




12 




15585860940 


Dispatch thread: el807a0 




22 


81 


15585833507 


EXIT: TEST.mcthod_X_exit 


35 


22 


2 


15585833507 


ENTRY: TEST.method_Y() 


22 


82 


15585833507 


EXIT: TESTmethod_Y_exit 



As shown in FIG. 5, a reference to the instrumentation 
class is added into the constant pool section of the class file 
(step 506). While there are more methods to hook (step 508), 
the following steps are performed. For each method, the 
entry point and one or more exit points are located (step 
510). An entry hook and exit hooks are inserted for the major 
and minor codes (step 512). Selective instrumentation is 
possible if only some of the methods are to be instrumented. 
In the described embodiment, an inclusion/exclusion list is 
used to specify which methods are to be instrumented. 
However, any number of procedures may be used to deter- 
mine whether a particular method is to be instrumented or to 
specify which methods are to be instrumented. 

On entry into a method, the following invocation is 
inserted: 

instrumentation Library.log(major_code,minor_code); 

Just prior to returning from the method, the following 
invocation is inserted: 

instrumentation Library.log(major_code,minor_code); 

There are often several exit points for a single method, 
and each exit point must be so instrumented. At post- 
processing time, the major codes and minor codes are 
resolved with specific method and class names from the 
HDF file. This allows collection to proceed without the 
overhead of recording large amounts of double-byte string 
data. 

Bytecode modification requires the insertion of Java byte- 
code instructions that affect the method invocations noted 
above. Insertion requires the identification of method bodies, 
interpretation of existing bytecodes, and location of entry 
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and exit points. It is critical that the modifications be 
consistent with the criteria employed by the class file 
verifier. The class file verifier ensures that the bytecode, and 
the rest of the class file, is valid and can be executed by the 
Java VM. Thus, the next step is to modify the other 
components of the class file to ensure that they satisfy the 
constraints of the class file verifier (step 514). Further details 
regarding step 514 are described below with reference to 
FIG. 6. 

Next, an entry is added to the HDF (step 516). The entry 
includes the major and minor codes, and method signature 
as the description. The minor code is then incremented to 
ensure that it is unique for each method (step 518). 

When there are no more methods to hook, the HDF is 
closed and written to the file system (step 520). The modified 
classj^flis^fenftcffa^ closed (step 524). 

The modified, or transformed, class file is then ready to be 
executed. 

Step 514 is depicted in greater detail in FIG. 6. As code 
is inserted in the existing stream for each method, verifica- 
tion is ensured by: 

1. Creating constant pool entries for the instrumentation 
class and methods (steps 506 and 516 in FIG. 5). 

2. Ensuring code that is moved is correctly relocated, and 
that all related references are adjusted for the relocation 
(step 514). 

As shown in FIG. 6, several steps must be taken to ensure 
that code which is moved due to either insertions or dele- 
tions is correctly relocated and related references are 
adjusted. First, the exception table is modified (step 602). In 
Java, an exception handler may be set up to handle specific 
exceptions that occur at specified line numbers. Adding or 
deleting code may change the line numbers associated with 
a particular exception handler. Therefore, the exception table 
may need to be adjusted so that the correct exception handler 
is called for exceptions which occur at certain line numbers. 

If a line number table is present (step 604), it is modified 
(step 606). Similarly, if a local variable table is present (step 
608), it is modified (step 610). For each relative jump 
address (step 612), it is first determined if the jump is a jump 
forward (step 614). If so, the next step is to determine if it 
is a jump around inserted code (step 616). If it is, the relative 
address is incremented by the insert length (step 618). If the 
jump is a jump backward (answer to step 614 is "no"), and 
the jump is around inserted code (step 620), then the relative 
address is decremented by the insert length (step 622). 

In the described embodiment, the instrumentation class is 
a separate and distinct Java class. Of course, different types 
of classes are used for different purposes. If the purpose of 
the code modifications is to change the functionality of the 
code, rather than to instrument the code, a different type of 
class may be used. There is also no requirement that the 
instrumentation class be a Java class. The instrumentation 
class could be a native class, and one skilled in the art would 
appreciate that appropriate linkages would have to be estab- 
lished in order to make calls to the native class. 

In the described embodiment, the instrumentation class 
exports several methods, including: 

1. log: Used to log entry/exit (or any other control point). 
Note that serialization is provided to ensure that more 
than one instrumented class can log simultaneously. 
Also note that logging will alternately be to a hardware 
or software trace capability, and logging may exploit 
native machine methods (i.e. methods that are written 
in assembly code, rather than Java) that make use of 
efficient machine timcstamp acquisition. 

2. Init: Initialized logging capability (e.g., allocates a 
buffer). 



3. Dump: Produces an output file of logged data. 
The following example depicts the source code of a Java 
class file being instrumented, a disassembly of the class file 
before it is hooked, and a disassembly of the same class file 
s after it is hooked. The example depicts how code (i.e. 
methods) in the class file can be modified. In this particular 
case, instrumentation books are inserted at method entry and 
exit(s) for performance measurement. Notice how the major 
and minor code for the hook is pushed on the stack with the 
10 short integer push ("sipush") instructions before a call 
(invokestatic instruction) is made to the "log" method of the 
instrumentation class. Three Java VM instructions are 
inserted for each entry or exit hook. Also note that in some 
cases, dummy instructions (e.g., iconst_0 and pop2) may be 
35 added to keep the inserted code size in multiples of four. 
This is done because some specific bytecode instructions 
require 4-byte alignment. In the example below, none of the 
instructions require 4-byte alignment; however, the dummy 
instructions are added as part of the described embodiment. 
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/* A Java class file named hello.java V 
class hello 

public static void main(String argsfj) 
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System.out .printing Hello, how are you today?"); 



} 

/* A disassembly of hello. class before it is hooked •/ 
compiled from hello.java 

synchronized class hello extends java.lang. Object 
/" ACC_SUPER bit set "/ 

{ 

public static void mainQ"ava.lang.Stringf D; 
helloO; 

Method void main(java.lang.String[]); 

0 getstauc #7 -cField java.io.PrintStram out> 

3 Idc #1 <String "Hello, how are you today?"> 

5 invokevirtual #8 

cMethod void println(java.lang.String)> 

8 return 
Method helloO 

0 aload_0 

1 in vok especial #6 <Mcthod java.lang.Object()> 

4 return 

/• A disassembly of hello. class after it is hooked •/ 
Compiled from hello.java 

synchronized class hello extends java.lang. Object 
/' ACC_SUPER bit set V 

public static void main(java.lang.Slring[D; 
helloO; 

} 

Method void main(java.Iang.STring[D 
0 sipush 2560 
3 sipush 1 

6 invokestatic #37 <Method void log(int,inl)> 

9 iconst_0 

10 icons l_0 

11 pop2 

12 getStatic #7 <Field java.io.PrintStream out> 
15 Idc #1 <String "Hello, how are you today?"> 
17 invokevirtual #8 

cMethod void prinUn(java.lang.Suing)> 
20 sipush 2688 
23 sipush 1 

26 invokestatic #37 <Method void log(int,int)> 

29 iconsl_0 

30 iconst_0 

31 pop2 

32 return 
Method helloO 

0 sipush 2560 
3 sipush 2 
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recoastnicting the class file; and 

-continued verifying the reconstructed class file to ensure that it will 

6 invokcstiltic #37 <Mclhod void Iog(inljinl)> work in its intended operating environment. 

9 iconst 0 

2. A method for modifying a class file according to claim 

10 iconsi_o 5 l > wherein said deconstructing step is performed by a class 

11 p°p 2 file reader. 

13 to™k4<=cial #6 <M«hod java.b>ng.ObjectO> 3 A method for w*}^ a class file according to claim 

1 6 sipush 26S8 1> wherein said modifying step further comprises the step of 

19 sipush 2 modifying a constant pool section of the class file. 

22 invokesiatic #37 <Method void !ogfinUni)> io 4. a method for modifying a class file according to claim 

26 !consi~o wnere ' n said modifying step further comprises the step of 

27 pop2 ~ modifying one or more code attributes of the class file. 

28 return S. A method for modifying a class file according to claim 
— ~~ ~ ~~ ^ ~" ~ " _— — ~~ — 1, wherein said modifying step further comprises the step of 

Referring now to FIG. 7, which shows a flow chart of the 15 modifying an exception table, 

execution of a modified method, as shown at step 702, the , 6 - A me,hod for modifying a class file according to claim 

code is executing inside a modified method in class A. The ^ h ! rem Mld modifying step further comprises the step of 

reader will recall that code was injected in class A, such as modifying a line number table 

the instrumentation hooks, as was described in the foregoing ,„ , 7 - A me,hod , for modifying a f la f file according to claim 

example. Those skilled in the art will appreciate that other 20 *; h f erem M,d modifying step further composes the step of 

types of code performing other functions could be called by modifying a local variable table. 

the injected code according to the present invention. This is , 8 - A method 1 for a class fi,e according to claim 

done before calling the instrumentation class to allow for *• "*?? m Mld modifying step further comprises the step of 

performance measurement. The injected code in class A calls „ modifying ° n <= or more relative jump addresses, 

a method in class B (Step 704), preferably a Java class. The * , »■ A method for modifyuig a class file accordmg to claim 

called method is executed in class B, e.g., an instrumentation X ' wherem Mld modifying step further comprises the step of 

method, and then returns back to the method in class A (step ^""8 an enlrv ,nto a definition file for each mod.fied class 

706) to the code injected in class A (step 708). At this point, file component. 

any needed clean-up is performed by the injected code in „ „ 10. A method for modifying a class file according to claim 

class A (step 708). Execution inside the method in class A 30 9 - wherein the entr y comprises a major code, a minor code, 

then continues (step 710). As described above, the called a c , ,ass nam ^' a ° d a m ^ od signature 

method could be in native code not necessarily associated , U A method for modifying a class file according to claim 

with a given Java class l - wherem said verifying step comprises the step of venfy- 

Although the invention has been described with a certain „ m B tha | the reconstructed class file follows one or more 

degree of particularity, it should be recognized that elements 35 constraints imposed by a class fi e verifier, 

thereof may be altered by persons skilled in the art without , U - A me,hod , for modifying a class fi ]e according to claim 

departing from the spirit and scope of the invention. One of l - wherem me class file 15 a Java class ®*> and wher f 10 

the preferred implementations of the invention is as sets of venf y ,n & ste P comprises the step of verifying that the 

instructions resident in the random access memory 16 of one reconstructed Java class file will execute in a Java virtual 

or more computer systems configured generally as described machine environment 

in FIG. 1. Until required by the computer system, the set of , 13 u A melhod for modifying a class file according to claim 

instructions may be stored in another computer readable 1, wherein sa.d modifying step comprises the step of adding 

memory, for example in a hard disk drive, or in a removable instrumentation code to one or more of the class file com- 

memory such as an optical disk for eventual use in a A . P on ^ nts - . t _ 

CD-ROM drive or a floppy disk for eventual use in a floppy 45 , ' mctn °d for modifying a class file according to claim 

diskdrive.Further,lhesetofinstmctionscanbestoredinthe 1, wherein said modrfying step compnses the step of adding 

memory of another computer and transmitted over a local 10 ODe or more ° f lhc , class file components in order to 

area network or a wide area network, such as the Internet, chan S c ,he &ncUonahty of the class file components, 

when desired by the user. One skilled in the art would <n , 15. A method for modifying a class file accordmg to clami 

appreciate that the physical storage of the sets of instructions 50 h whe "™ Mld modifying step comprises the step of delet- 

physically changes the medium upon which it is stored "* code from one L °' more ° f ,! ne c i ass file components in 

electrically, magnetically, or chemically so that the medium order to chan 8 e ,he functionality of the class file compo- 

carries computer readable information. The invention is nents. 

limited only by the following claims and their equivalents. « , 16 ' me, b° d & r modifying a class file according to claim 

What is claimed is' ' wherein the class file contains a security signature. 

1. A method for modifying a class file, comprising the 17 A c melhod for modi fy*g a class file, comprising the 

steps of: sle ^ of: 

deconstructing the class file into one or more class file deconstructing a class file loader into one or more class 

components; 60 file loader components; 

modifying one or more of the class file components, modifying one or more of the class file loader compo- 

wherein said modifying includes the following steps: nents, 

selecting one or more methods in the class file; reconstructing the class file loader, wherein the recon- 

adding one or more lines of code to an entry point in structed class file loader follows one or more class file 

each selected method; and 65 constraints imposed by a class file verifier; 

adding one or more lines of code to one or more exit downloading a class file using the modified class file 

points in each selected method; loader; 



06/23/2004, EAST version: 1.4.1 



6,a 

11 

deconstructing the class file into one or more class file 
components; 

modifying one or more of the class file components; and 
reconstructing the class file, wherein the reconstructed 

class file follows the one or more class file constraints 

imposed by the class file verifier 

18. A method for modifying a class file according to claim 
17, wherein said downloading step further comprises the 
step of intercepting the class file and transforming its 
memory image. 

19. A method for intercepting and modifying a class file 
as it is being downloaded from a network, comprising the 
steps of: 

deconstructing a class file loader into one or more class 
file loader components; 

modifying one or more of the class file loader compo- 
nents; 

reconstructing the class file loader, wherein the recon- 
structed class file loader follows one or more class file 
constraints imposed by a class file verifier; 

downloading a class file using the modified class file 
loader; 

deconstructing the class file into one or more class file 
components; 

modifying one or more of the class file components; and 
reconstructing the class file, wherein the reconstructed 

class file follows the one or more class file constraints 

imposed by the class file verifier. 

20. A method for executing a Java applet, comprising the 
steps of: 

accepting the Java applet from a server; 

modifying the Java applet by injecting linkage informa- 
tion to a new method into the Java applet; and 

executing the modified Java applet wherein the modified 
Java applet calls the new method as part of its execu- 
tion. 

21. A method for executing a Java applet according to 
claim 20, wherein said modifying step comprises the steps 
of: 

deconstructing a class file loader into one or more class 
file loader components, wherein the class file loader is 
a program within a browser; 

modifying one or more of the class file loader compo- 
nents; 

reconstructing the class file loader, wherein the recon- 
structed class file loader follows one or more class file 
constraints imposed by a class file verifier; 

downloading a class file using the modified class file 
loader; 

deconstructing the class file into one or more class file 
components; 

modifying one or more of the class file components; and 
reconstructing the class file, wherein the reconstructed 

class file follows the one or more class file constraints 

imposed by the class file verifier. 

22. An information handling system, comprising: 
one or more processors; 

memory means for storing instructions and data for use by 

the processors; 
one or more images of an operating system for controlling 

the operation of the processors; 
an input/output system for communicating information to 

and from peripheral devices; 
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at least one system bus connecting the elements of the 

system for efficient operation; and 
means for modifying a class file, wherein said means for 
modifying a class file includes: 
5 means for deconstructing the class file into one or more 
class file components; 
means for modifying one or more of the class file 
components, wherein said means for modifying one 
or more of the class file components includes: 
10 means for selecting one or more methods in the class 

file; 

means for adding one or more lines of code to an 

entry point in each selected method; and 
means for adding one or more lines of code to one or 
15 more exit points in each selected method; 

means for reconstructing the class file; and 
means for verifying the reconstructed class file to 
ensure that it will work in its intended operating 
environment. 

20 23. The information handling system of claim 22 wherein 
the class file is a Java class file. 

24. The information handling system of claim 22 wherein 
the means for modifying one or more of the class file 
components further comprises means for adding instrumen- 

25 tation code to one or more of the class file components. 

25. An information handling system, comprising: 
one or more processors; 

memory means for storing instructions and data for use by 
3Q the processors; 

one or more images of an operating system for controlling 

the operation of the processors; 
an input/output system for communicating information to 
and from peripheral devices; 
35 at least one system bus connecting the elements of the 
system for efficient operation; 
means for modifying a class file comprising: 

means for deconstructing a class file loader into one or 
more class file loader components; 
40 means for modifying one or more of the class file loader 
components; 

means for reconstructing the class file loader, wherein 
the reconstructed class file loader follows one or 
more class file constraints imposed by a class file 
45 verifier; 

means for downloading a class file using the modified 

class file loader; 
means for deconstructing the class file into one or more 
class file components; 
50 means for modifying one or more of the class file 
components; and 
means for reconstructing the class file, wherein the 
reconstructed class file follows the one or more class 
file constraints imposed by the class file verifier. 
55 26. An information handling system, comprising: 
one or more processors; 

memory means for storing instructions and data for use by 
the processors; 

6Q one or more images of an operating system for controlling 
the operation of the processors; 
an input/output system for communicating information to 

and from peripheral devices; 
at least one system bus connecting the elements of the 
55 system for efficient operation; 

means for intercepting and modifying a class file as it is 
being downloaded from a network, comprising: 
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means for deconstructing a class file loader into one or 

more class file loader components; 
means for modifying one or more of the class file loader 

components; 

means for reconstructing the class file loader, wherein 
the reconstructed class file loader follows one or 
more class file constraints imposed by a class file 

means for downloading a class file using the modified 
class file loader; 

means for deconstructing the class file into one or more 
class file components; 

means for modifying one or more of the class file 
components; and 

means for reconstructing the class file, wherein the 
reconstructed class file follows the one or more class 
file constraints imposed by the class file verifier. 

27. An information handling system, comprising: 
one or more processors; 

memory means for storing instructions and data for use by 

the processors; 
one or more images of an operating system for controlling 

the operation of the processors; 
an input/output system for communicating information to 

and from peripheral devices; 
at least one system bus connecting the elements of the 

system for efficient operation; 
means for executing a Java applet comprising: 

means for accepting the Java applet from a server; 

means for modifying the Java applet by injecting a new 
class into the Java applet; and 

means for executing the modified Java applet. 

28. The information handling system of claim 27 wherein 
the means for modifying further comprises: 

means for deconstructing a class file loader into one or 
more class file loader components, wherein the class 
file loader is a program within a browser; 

means for modifying one or more of the class file loader 
components; 

means for reconstructing the class file loader, wherein the 
reconstructed class file loader follows one or more class 
file constraints imposed by a class file verifier; 

means for downloading a class file using the modified 
class file loader; 

means for deconstructing the class file into one or more 
class file components; 

means for modifying one or more of the class file com- 
ponents; and 

means for reconstructing the class file, wherein the recon- 
structed class file follows the one or more class file 
constraints imposed by the class file verifier. 

29. A computer readable medium, comprising: 
means for modifying a class file comprising: 

means for deconstructing a class file loader into one or 

more class file loader components; 
means for modifying one or more of the class file loader 

components; 

means for reconstructing the class file loader, wherein 
the reconstructed class file loader follows one or 
more class file constraints imposed by a class file 
verifier; 

means for downloading a class file using the modified 

class file loader; 
means for deconstructing the class file into one or more 

class file components; 
means for modifying one or more of the class file 

components; and 
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means for reconstructing the class file, wherein the 
reconstructed class file follows the one or more class 
file constraints imposed by the class file verifier. 

30. A computer readable medium, comprising: 

means for intercepting and modifying a class file as it is 
being downloaded from a network, comprising: 
means for deconstructing a class file loader into one or 

more class file loader components; 
means for modifying one or more of the class file loader 

components; 

means for reconstructing the class file loader, wherein 
the reconstructed class file loader follows one or 
more class file constraints imposed by a class file 
verifier; 

means for downloading a class file using the modified 

class file loader; 
means for deconstructing the class file into one or more 

class file components; 
means for modifying one or more of the class file 

components; and 
means for reconstructing the class file, wherein the 

reconstructed class file follows the one or more class 

file constraints imposed by the class file verifier. 

31. A computer readable medium, comprising: 
means for executing a Java applet comprising: 

means for accepting the Java applet from a server; 
means for modifying the Java applet by injecting a new 

class into the Java applet; and 
means for executing the modified Java applet. 

32. A method for modifying a class file, comprising the 
steps of: 

deconstructing the class file into one or more class file 
components; 

modifying one or more of the class file components, 
wherein said modifying includes the step of writing an 
entry into a definition file for each modified class file 
component; 

reconstructing the class file; and 

verifying the reconstructed class file to ensure that it will 
work in its intended operating environment. 

33. A method for modifying a class file according to claim 
32, wherein said deconstructing step is performed by a class 
file reader. 

34. A method for modifying a class file according to claim 
32, wherein said modifying step further comprises the step 
of modifying a constant pool section of the class file. 

35. A method for modifying a class file according to claim 
32, wherein said modifying step further comprises the step 
of modifying one or more code attributes of the class file. 

36. A method for modifying a class file according to claim 
32, wherein said modifying step further comprises the step 
of modifying an exception table. 

37. A method for modifying a class file according to claim 
32, wherein said modifying step further comprises the step 
of modifying a line number table. 

38. A method for modifying a class file according to claim 
32, wherein said modifying step further comprises the step 
of modifying a local variable table. 

39. A method for modifying a class file according to claim 
32, wherein said modifying step further comprises the step 
of modifying one or more relative jump addresses. 

40. A method for modifying a class file according to claim 
32, wherein the entry comprises a major code, a minor code, 
a class name, and a method signature. 

41. A method for modifying a class file according to claim 
32, wherein said verifying step comprises the step of veri- 
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fyiag that the reconstructed class file follows one or more 48. A method for modifying a class file according to claim 

constraints imposed by a class file verifier. 44, wherein said modifying step further comprises the step 

42. A method for modifying a class file according to claim Q f modifying an exception table. 

32, wherein the class file is a Java class file, and wherein said 49 A me thod for modifying a class file according to claim 

verifying step comprises the step of verifying that the 5 44^ wherei n said modifying step further comprises the step 

reconstructed Java class file will execute in a Java virtual of modif m a Une number lable 

machine environment. en ' ~ . 

43. Amethod for modifying a class file according to claim 50. Amethod for modifying a class file accordmg to claim 
32, wherein said modifying step comprises the step of <4> wherem said modifying step further comprises the step 
adding instrumentation code to one or more of the class file 10 of modifying a local variable table. 

components. 51. A method for modifying a class file according to claim 

44. A method for modifying a class file, the class file 44, wherein said modifying step further comprises the step 
containing a security signature, comprising the steps of: of modifying one or more relative jump addresses. 

deconstructing the class file into one or more class file 52. A method for modifying a class file according to claim 

components; 15 44, wherein said verifying step comprises the step of veri- 

modifying one or more of the class file components; fying that the reconstructed class file follows one or more 

reconstructing the class file; and constraints imposed by a class file verifier. 

. , . , ci . .u * 11 53. A method for modifying a class file according to claim 

verifying the reconstructed class file to ensure that it will ...... c . - f , c , j i_ • j 

work in its intended operating environment. 20 ^4, wherem the class file b a Java class file, and wherem said 

45. A method for modifying a class file according to claim sle P comprises the step of verifying that the 
44, wherein said deconstructing step is performed by a class reconstructed Java class file will execute in a Java virtual 
file reader. machine environment. 

46. A method for modifying a class file according to claim 54 A method for modifying a class file according to claim 
44, wherein said modifying step further comprises the step 25 44, wherein said modifying step comprises the step of 
of modifying a constant pool section of the class file. adding instrumentation code to one or more of the class file 

47. A method for modifying a class file according to claim components. 
44, wherein said modifying step further comprises the step 

of modifying one or more code attributes of the class file. ***** 
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